home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 7 / Apprentice-Release7.iso / Environments / PowerLisp 2.01 / Supplemental Documentation / Documentation / Chapter 01. Introduction < prev    next >
Text File  |  1995-03-27  |  27KB  |  574 lines

  1. Common Lisp the Language, 2nd Edition
  2. -------------------------------------------------------------------------------
  3.  
  4.  
  5. 1. Introduction
  6.  
  7. Common Lisp is a new dialect of Lisp, a successor to MacLisp [33,37],
  8. influenced strongly by Zetalisp [55,34] and to some extent by Scheme [46] and
  9. Interlisp [50].
  10.  
  11. -------------------------------------------------------------------------------
  12.  
  13.    *  Purpose
  14.    *  Notational Conventions
  15.         o  Decimal Numbers
  16.         o  Nil, False, and the Empty List
  17.         o  Evaluation, Expansion, and Equivalence
  18.         o  Errors
  19.         o  Descriptions of Functions and Other Entities
  20.         o  The Lisp Reader
  21.         o  Overview of Syntax
  22.  
  23. -------------------------------------------------------------------------------
  24.  
  25.  
  26. 1.1. Purpose
  27.  
  28. Common Lisp is intended to meet these goals:
  29.  
  30. Commonality
  31.      Common Lisp originated in an attempt to focus the work of several
  32.      implementation groups, each of which was constructing successor
  33.      implementations of MacLisp for different computers. These implementations
  34.      had begun to diverge because of the differences in the implementation
  35.      environments: microcoded personal computers (Zetalisp, Spice Lisp),
  36.      commercial timeshared computers (NIL-the ``New Implementation of Lisp''),
  37.      and supercomputers (S-1 Lisp). While the differences among the several
  38.      implementation environments of necessity will continue to force certain
  39.      incompatibilities among the implementations, Common Lisp serves as a
  40.      common dialect to which each implementation makes any necessary
  41.      extensions.
  42.  
  43. Portability
  44.  
  45.      Common Lisp intentionally excludes features that cannot be implemented
  46.      easily on a broad class of machines. On the one hand, features that are
  47.      difficult or expensive to implement on hardware without special microcode
  48.      are avoided or provided in a more abstract and efficiently implementable
  49.      form. (Examples of this are the invisible forwarding pointers and
  50.      locatives of Zetalisp. Some of the problems that they solve are addressed
  51.      in different ways in Common Lisp.) On the other hand, features that are
  52.      useful only on certain ``ordinary'' or ``commercial'' processors are
  53.      avoided or made optional. (An example of this is the type declaration
  54.      facility, which is useful in some implementations and completely ignored
  55.      in others. Type declarations are completely optional and for correct
  56.      programs affect only efficiency, not semantics.) Common Lisp is designed
  57.      to make it easy to write programs that depend as little as possible on
  58.      machine-specific characteristics, such as word length, while allowing some
  59.      variety of implementation techniques.
  60.  
  61. Consistency
  62.      Most Lisp implementations are internally inconsistent in that by default
  63.      the interpreter and compiler may assign different semantics to correct
  64.      programs. This semantic difference stems primarily from the fact that the
  65.      interpreter assumes all variables to be dynamically scoped, whereas the
  66.      compiler assumes all variables to be local unless explicitly directed
  67.      otherwise. This difference has been the usual practice in Lisp for the
  68.      sake of convenience and efficiency but can lead to very subtle bugs. The
  69.      definition of Common Lisp avoids such anomalies by explicitly requiring
  70.      the interpreter and compiler to impose identical semantics on correct
  71.      programs so far as possible.
  72.  
  73. Expressiveness
  74.      Common Lisp culls what experience has shown to be the most useful and
  75.      understandable constructs from not only MacLisp but also Interlisp, other
  76.      Lisp dialects, and other programming languages. Constructs judged to be
  77.      awkward or less useful have been excluded. (An example is the store
  78.      construct of MacLisp.)
  79.  
  80. Compatibility
  81.      Unless there is a good reason to the contrary, Common Lisp strives to be
  82.      compatible with Lisp Machine Lisp, MacLisp, and Interlisp, roughly in that
  83.      order.
  84.  
  85. Efficiency
  86.      Common Lisp has a number of features designed to facilitate the production
  87.      of high-quality compiled code in those implementations whose developers
  88.      care to invest effort in an optimizing compiler. One implementation of
  89.      Common Lisp, namely S-1 Lisp, already has a compiler that produces code
  90.      for numerical computations that is competitive in execution speed to that
  91.      produced by a Fortran compiler [11]. The S-1 Lisp compiler extends the
  92.      work done in MacLisp to produce extremely efficient numerical code [19].
  93.  
  94. Power
  95.      Common Lisp is a descendant of MacLisp, which has traditionally placed
  96.      emphasis on providing system-building tools. Such tools may in turn be
  97.      used to build the user-level packages such as Interlisp provides; these
  98.      packages are not, however, part of the Common Lisp core specification. It
  99.      is expected such packages will be built on top of the Common Lisp core.
  100.  
  101. Stability
  102.      It is intended that Common Lisp will change only slowly and with due
  103.      deliberation. The various dialects that are supersets of Common Lisp may
  104.      serve as laboratories within which to test language extensions, but such
  105.      extensions will be added to Common Lisp only after careful examination and
  106.      experimentation.
  107.  
  108. The goals of Common Lisp are thus very close to those of Standard Lisp [31] and
  109. Portable Standard Lisp [51]. Common Lisp differs from Standard Lisp primarily
  110. in incorporating more features, including a richer and more complicated set of
  111. data types and more complex control structures.
  112.  
  113. This book is intended to be a language specification rather than an
  114. implementation specification (although implementation notes are scattered
  115. throughout the text). It defines a set of standard language concepts and
  116. constructs that may be used for communication of data structures and algorithms
  117. in the Common Lisp dialect. This set of concepts and constructs is sometimes
  118. referred to as the ``core Common Lisp language'' because it contains
  119. conceptually necessary or important features. It is not necessarily
  120. implementationally minimal. While many features could be defined in terms of
  121. others by writing Lisp code, and indeed may be implemented that way, it was
  122. felt that these features should be conceptually primitive so that there might
  123. be agreement among all users as to their usage. (For example, bignums and
  124. rational numbers could be implemented as Lisp code given operations on fixnums.
  125. However, it is important to the conceptual integrity of the language that they
  126. be regarded by the user as primitive, and they are useful enough to warrant a
  127. standard definition.)
  128.  
  129. For the most part, this book defines a programming language, not a programming
  130. environment. A few interfaces are defined for invoking such standard
  131. programming tools as a compiler, an editor, a program trace facility, and a
  132. debugger, but very little is said about their nature or operation. It is
  133. expected that one or more extensive programming environments will be built
  134. using Common Lisp as a foundation, and will be documented separately.
  135.  
  136. [change_begin]
  137. There are now many implementations of Common Lisp, some programmed by research
  138. groups in universities and some by companies that sell them commercially, and a
  139. number of useful programming environments have indeed grown up around these
  140. implementations. What is more, all the goals stated above have been achieved,
  141. most notably that of portability. Moving large bodies of Lisp code from one
  142. computer to another is now routine.
  143. [change_end]
  144.  
  145.  
  146. 1.2. Notational Conventions
  147.  
  148. A number of special notational conventions are used throughout this book for
  149. the sake of conciseness.
  150.  
  151. -------------------------------------------------------------------------------
  152.  
  153.    *  Decimal Numbers
  154.    *  Nil, False, and the Empty List
  155.    *  Evaluation, Expansion, and Equivalence
  156.    *  Errors
  157.    *  Descriptions of Functions and Other Entities
  158.    *  The Lisp Reader
  159.    *  Overview of Syntax
  160.  
  161. -------------------------------------------------------------------------------
  162.  
  163.  
  164. 1.2.1. Decimal Numbers
  165.  
  166. All numbers in this book are in decimal notation unless there is an explicit
  167. indication to the contrary. (Decimal notation is normally taken for granted, of
  168. course. Unfortunately, for certain other dialects of Lisp, MacLisp in
  169. particular, the default notation for numbers is octal (base 8) rather than
  170. decimal, and so the use of decimal notation for describing Common Lisp is,
  171. taken in its historical context, a bit unusual!)
  172.  
  173.  
  174. 1.2.2. Nil, False, and the Empty List
  175.  
  176. In Common Lisp, as in most Lisp dialects, the symbol nil is used to represent
  177. both the empty list and the ``false'' value for Boolean tests. An empty list
  178. may, of course, also be written (); this normally denotes the same object as
  179. nil. (It is possible, by extremely perverse manipulation of the package system,
  180. to cause the sequence of letters nil to be recognized not as the symbol that
  181. represents the empty list but as another symbol with the same name. This
  182. obscure possibility will be ignored in this book.) These two notations may be
  183. used interchangeably as far as the Lisp system is concerned. However, as a
  184. matter of style, this book uses the notation () when it is desirable to
  185. emphasize the use of an empty list, and uses the notation nil when it is
  186. desirable to emphasize the use of the Boolean ``false''. The notation 'nil
  187. (note the explicit quotation mark) is used to emphasize the use of a symbol.
  188. For example:
  189.  
  190. (defun three () 3)      ;Emphasize empty parameter list
  191.  
  192. (append '() '()) => ()  ;Emphasize use of empty lists
  193.  
  194. (not nil) => t          ;Emphasize use as Boolean ``false''
  195.  
  196. (get 'nil 'color)       ;Emphasize use as a symbol
  197.  
  198. Any data object other than nil is construed to be Boolean ``not false'', that
  199. is, ``true''. The symbol t is conventionally used to mean ``true'' when no
  200. other value is more appropriate. When a function is said to ``return false'' or
  201. to ``be false'' in some circumstance, this means that it returns nil. However,
  202. when a function is said to ``return true'' or to ``be true'' in some
  203. circumstance, this means that it returns some value other than nil, but not
  204. necessarily t.
  205.  
  206.  
  207. 1.2.3. Evaluation, Expansion, and Equivalence
  208.  
  209. Execution of code in Lisp is called evaluation because executing a piece of
  210. code normally results in a data object called the value produced by the code.
  211. The symbol => is used in examples to indicate evaluation. For example,
  212.  
  213. (+ 4 5) => 9
  214.  
  215. means ``the result of evaluating the code (+ 4 5) is (or would be, or would
  216. have been) 9.''
  217.  
  218. The symbol -> is used in examples to indicate macro expansion. For example,
  219.  
  220. (push x v) -> (setf v (cons x v))
  221.  
  222. means ``the result of expanding the macro-call form (push x v) is (setf v (cons
  223. x v)).'' This implies that the two pieces of code do the same thing; the second
  224. piece of code is the definition of what the first does.
  225.  
  226. The symbol == is used in examples to indicate code equivalence. For example,
  227.  
  228. (gcd x (gcd y z)) == (gcd (gcd x y) z)
  229.  
  230. means ``the value and effects of evaluating the form (gcd x (gcd y z)) are
  231. always the same as the value and effects of (gcd (gcd x y) z) for any values of
  232. the variables x, y, and z.'' This implies that the two pieces of code do the
  233. same thing; however, neither directly defines the other in the way macro
  234. expansion does.
  235.  
  236.  
  237. 1.2.4. Errors
  238.  
  239. When this book specifies that it ``is an error'' for some situation to occur,
  240. this means that:
  241.  
  242.    *  No valid Common Lisp program should cause this situation to occur.
  243.  
  244.    *  If this situation occurs, the effects and results are completely
  245.      undefined as far as adherence to the Common Lisp specification is
  246.      concerned.
  247.  
  248.    *  No Common Lisp implementation is required to detect such an error. Of
  249.      course, implementors are encouraged to provide for detection of such
  250.      errors wherever reasonable.
  251.  
  252. This is not to say that some particular implementation might not define the
  253. effects and results for such a situation; the point is that no program
  254. conforming to the Common Lisp specification may correctly depend on such
  255. effects or results.
  256.  
  257. On the other hand, if it is specified in this book that in some situation ``an
  258. error is signaled,'' this means that:
  259.  
  260.    *  If this situation occurs, an error will be signaled (see error and
  261.      cerror).
  262.  
  263.    *  Valid Common Lisp programs may rely on the fact that an error will be
  264.      signaled.
  265.  
  266.    *  Every Common Lisp implementation is required to detect such an error.
  267.  
  268. In places where it is stated that so-and-so ``must'' or ``must not'' or ``may
  269. not'' be the case, then it ``is an error'' if the stated requirement is not
  270. met. For example, if an argument ``must be a symbol,'' then it ``is an error''
  271. if the argument is not a symbol. In all cases where an error is to be signaled,
  272. the word ``signaled'' is always used explicitly in this book.
  273.  
  274. [change_begin]
  275. X3J13 has adopted a more elaborate terminology for errors, and has made some
  276. effort to specify the type of error to be signaled in situations where
  277. signaling is appropriate. This effort was not complete as of September 1989,
  278. and I have made little attempt to incorporate the new error terminology or
  279. error type specifications in this book. However, the new terminology is
  280. described and used in the specification of the Common Lisp Object System
  281. appearing in chapter 28; this gives the flavor of how erroneous situations will
  282. be described, and appropriate actions prescribed, in the forthcoming ANSI
  283. Common Lisp standard.
  284. [change_end]
  285.  
  286.  
  287. 1.2.5. Descriptions of Functions and Other Entities
  288.  
  289. Functions, variables, named constants, special forms, and macros are described
  290. using a distinctive typographical format. Table 1-1 illustrates the manner in
  291. which Common Lisp functions are documented. The first line specifies the name
  292. of the function, the manner in which it accepts arguments, and the fact that it
  293. is a function. If the function takes many arguments, then the names of the
  294. arguments may spill across two or three lines. The paragraphs following this
  295. standard header explain the definition and uses of the function and often
  296. present examples or related functions.
  297.  
  298. Sometimes two or more related functions are explained in a single combined
  299. description. In this situation the headers for all the functions appear
  300. together, followed by the combined description.
  301.  
  302. In general, actual code (including actual names of functions) appears in this
  303. typeface: (cons a b). Names that stand for pieces of code (metavariables) are
  304. written in italics. In a function description, the names of the parameters
  305. appear in italics for expository purposes. The word &optional in the list of
  306. parameters indicates that all arguments past that point are optional; the
  307. default values for the parameters are described in the text. Parameter lists
  308. may also contain &rest, indicating that an indefinite number of arguments may
  309. appear, or &key, indicating that keyword arguments are accepted. (The
  310. &optional/&rest/&key syntax is actually used in Common Lisp function
  311. definitions for these purposes.)
  312.  
  313.  
  314. ----------------------------------------------------------------
  315. Table 1-1: Sample Function Description
  316.  
  317. [Function]
  318. sample-function arg1 arg2 &optional arg3 arg4
  319.  
  320. The function sample-function adds together arg1 and arg2,
  321. and then multiplies the result by arg3. If arg3 is not
  322. provided or is nil, the multiplication isn't done.
  323. sample-function then returns a list whose first element is
  324. this result and whose section element is arg4 (which
  325. defaults to the symbol foo). For example:
  326.  
  327. (sample-function 3 4) => (7 foo)
  328. (sample-function 1 2 2 'bar) => (6 bar)
  329.  
  330. In general, (sample-function x y) == (list (+ x y) 'foo).
  331.  
  332. ----------------------------------------------------------------
  333.  
  334.  
  335. ----------------------------------------------------------------
  336. Table 1-2: Sample Variable Description
  337.  
  338. [Variable]
  339. *sample-variable*
  340.  
  341. The variable *sample-variable* specifies how many times the
  342. special form sample-special-form should iterate. The value
  343. should always be a non-negative integer or nil (which means
  344. iterate indefinitely many times).  The initial value is 0
  345. (meaning no iterations).
  346.  
  347. ----------------------------------------------------------------
  348.  
  349.  
  350. ----------------------------------------------------------------
  351. Table 1-3: Sample Constant Description
  352.  
  353. [Constant]
  354. sample-constant
  355.  
  356. The named constant sample-constant has as its value the
  357. height of the terminal screen in furlongs times the base-2
  358. logarithm of the implementation's total disk capacity in
  359. bytes, as a floating-point number.
  360.  
  361. ----------------------------------------------------------------
  362.  
  363. Table 1-2 illustrates the manner in which a global variable is documented. The
  364. first line specifies the name of the variable and the fact that it is a
  365. variable. Purely as a matter of convention, all global variables used by Common
  366. Lisp have names beginning and ending with an asterisk.
  367.  
  368. Table 1-3 illustrates the manner in which a named constant is documented. The
  369. first line specifies the name of the constant and the fact that it is a
  370. constant. (A constant is just like a global variable, except that it is an
  371. error ever to alter its value or to bind it to a new value.)
  372.  
  373.  
  374. ----------------------------------------------------------------
  375. Table 1-4: Sample Special Form Description
  376.  
  377. [Special Form]
  378. sample-special-form [name] ({var}*) {form}+
  379.  
  380. This evaluates each form in sequence as an implicit progn,
  381. and does this as many times as specified by the global
  382. variable *sample-variable*. Each variable var is
  383. bound and initialized to 43 before the first iteration, and
  384. unbound after the last iteration. The name name, if
  385. supplied, may be used in a return-from form to exit from the
  386. loop prematurely. If the loop ends normally,
  387. sample-special-form returns nil. For example:
  388.  
  389. (setq *sample-variable* 3)
  390. (sample-special-form () form1 form2)
  391.  
  392. This evaluates form1, form2, form1, form2, form1, form2,
  393. in that order.
  394.  
  395. ----------------------------------------------------------------
  396.  
  397.  
  398. ----------------------------------------------------------------
  399. Table 1-5: Sample Macro Description
  400.  
  401. [Macro]
  402. sample-macro var [[ declaration* | doc-string ]] {tag | statement}*
  403.  
  404. This evaluates the statements as a prog body, with the
  405. variable var bound to 43.
  406.  
  407. (sample-macro x (return (+ x x))) => 86
  408. (sample-macro var . body) -> (prog ((var 43)) . body)
  409. ----------------------------------------------------------------
  410.  
  411. Tables 1-4 and 1-5 illustrate the documentation of special forms and macros,
  412. which are closely related in purpose. These are very different from functions.
  413. Functions are called according to a single, specific, consistent syntax; the
  414. &optional/&rest/&key syntax specifies how the function uses its arguments
  415. internally but does not affect the syntax of a call. In contrast, each special
  416. form or macro can have its own idiosyncratic syntax. It is by special forms and
  417. macros that the syntax of Common Lisp is defined and extended.
  418.  
  419. In the description of a special form or macro, an italicized word names a
  420. corresponding part of the form that invokes the special form or macro.
  421. Parentheses stand for themselves and should be written as such when invoking
  422. the special form or macro. Brackets, braces, stars, plus signs, and vertical
  423. bars are metasyntactic marks. Brackets, [ and ], indicate that what they
  424. enclose is optional (may appear zero times or one time in that place); the
  425. square brackets should not be written in code. Braces, { and }, simply
  426. parenthesize what they enclose but may be followed by a star, *, or a plus
  427. sign, +; a star indicates that what the braces enclose may appear any number of
  428. times (including zero, that is, not at all), whereas a plus sign indicates that
  429. what the braces enclose may appear any non-zero number of times (that is, must
  430. appear at least once). Within braces or brackets, a vertical bar, |, separates
  431. mutually exclusive choices. In summary, the notation {x}* means zero or more
  432. occurrences of x, the notation {x}+ means one or more occurrences of x, and the
  433. notation [x] means zero or one occurrence of x. These notations are also used
  434. for syntactic descriptions expressed as BNF-like productions, as in table 22-2.
  435.  
  436. [change_begin]
  437. Double brackets, [[ and ]], indicate that any number of the alternatives
  438. enclosed may be used, and those used may occur in any order, but each
  439. alternative may be used at most once unless followed by a star. For example,
  440.  
  441.  p [[x | {y}* | z]] q
  442.  
  443. means that at most one x, any number of y's, and at most one z may appear
  444. between the mandatory occurrences of p and q, and those that appear may be in
  445. any order.
  446.  
  447. A downward arrow, [?], indicates a form of syntactic indirection that helps to
  448. make
  449. [[ ]] notation more readable. If X is some non-terminal symbol occurring on the
  450. left-hand side of some BNF production, then the right-hand side of that
  451. production is to be textually substituted for any occurrence of [?]X. Thus the
  452. two fragments
  453.  
  454. p [[[?]xyz-mixture]] q
  455. xyz-mixture ::= x | {y}* | z
  456.  
  457. are together equivalent to the previous example.
  458. [change_end]
  459.  
  460. In the last example in table 1-5, notice the use of dot notation. The dot
  461. appearing in the expression (sample-macro var . body) means that the name body
  462. stands for a list of forms, not just a single form, at the end of a list. This
  463. notation is often used in examples.
  464.  
  465. [change_begin]
  466. In the heading line in table 1-5, notice the use of [[ ]] notation to indicate
  467. that any number of declarations may appear but at most one documentation string
  468. (which may appear before, after, or somewhere in the middle of any
  469. declarations).
  470. [change_end]
  471.  
  472.  
  473. 1.2.6 The Lisp Reader
  474.  
  475. The term ``Lisp reader'' refers not to you, the reader of this book, nor to
  476. some person reading Lisp code, but specifically to a Lisp procedure, namely the
  477. function read, which reads characters from an input stream and interprets them
  478. by parsing as representations of Lisp objects.
  479.  
  480.  
  481. 1.2.7. Overview of Syntax
  482.  
  483. Certain characters are used in special ways in the syntax of Common Lisp. The
  484. complete syntax is explained in detail in chapter 22, but a quick summary here
  485. may be useful:
  486.  
  487. (    A left parenthesis begins a list of items. The list may contain any number
  488.      of items, including zero. Lists may be nested. For example, (cons (car x)
  489.      (cdr y)) is a list of three things, of which the last two are themselves
  490.      lists.
  491.  
  492. )    A right parenthesis ends a list of items.
  493.  
  494. '    An acute accent (also called single quote or apostrophe) followed by an
  495.      expression form is an abbreviation for (quote form). Thus 'foo means
  496.      (quote foo) and '(cons 'a 'b) means (quote (cons (quote a) (quote b))).
  497.  
  498. ;    Semicolon is the comment character. It and all characters up to the end of
  499.      the line are discarded.
  500.  
  501. "    Double quotes surround character strings:
  502.      "This is a thirty-nine-character string."
  503.  
  504. \    Backslash is an escape character. It causes the next character to be
  505.      treated as a letter rather than for its usual syntactic purpose. For
  506.      example, A\(B denotes a symbol whose name consists of the three characters
  507.      A, (, and B. Similarly, "\"" denotes a character string containing one
  508.      character, a double quote, because the first and third double quotes serve
  509.      to delimit the string, and the second double quote serves as the contents
  510.      of the string. The backslash causes the second double quote to be taken
  511.      literally and prevents it from being interpreted as the terminating
  512.      delimiter of the string.
  513.  
  514. |    Vertical bars are used in pairs to surround the name (or part of the name)
  515.      of a symbol that has many special characters in it. It is roughly
  516.      equivalent to putting a backslash in front of every character so
  517.      surrounded. For example, |A(B)|, A|(|B|)|, and A\(B\) all mean the symbol
  518.      whose name consists of the four characters A, (, B, and ).
  519.  
  520. #    The number sign signals the beginning of a complicated syntactic
  521.      structure. The next character designates the precise syntax to follow. For
  522.      example, #o105 means    (105 in octal notation); #x105 means    (105 in
  523.      hexadecimal notation); #b1011 means    (1011 in binary notation); #\L
  524.      denotes a character object for the character L; and #(a b c) denotes a
  525.      vector of three elements a, b, and c. A particularly important case is
  526.      that #'fn means (function fn), in a manner analogous to 'form meaning
  527.      (quote form).
  528.  
  529. `    Grave accent (``backquote'') signals that the next expression is a
  530.      template that may contain commas. The backquote syntax represents a
  531.      program that will construct a data structure according to the template.
  532.  
  533. ,    Commas are used within the backquote syntax.
  534.  
  535. :    Colon is used to indicate which package a symbol belongs to. For example,
  536.      network:reset denotes the symbol named reset in the package named network.
  537.      A leading colon indicates a keyword, a symbol that always evaluates to
  538.      itself. The colon character is not actually part of the print name of the
  539.      symbol. This is all explained in chapter 11; until you read that, just
  540.      keep in mind that a symbol notated with a leading colon is in effect a
  541.      constant that evaluates to itself.
  542.  
  543. [change_begin]
  544. Notice of correction. In the first edition, the characters ``,'' and ``:'' at
  545. the left margin above were inadvertently omitted.
  546. [change_end]
  547.  
  548. Brackets, braces, question mark, and exclamation point (that is, [, ], {, }, ?,
  549. and !) are not used for any purpose in standard Common Lisp syntax. These
  550. characters are explicitly reserved to the user, primarily for use as macro
  551. characters for user-defined lexical syntax extensions (see section 22.1.3).
  552.  
  553. [old_change_begin]
  554. All code in this book is written using lowercase letters. Common Lisp is
  555. generally insensitive to the case in which code is written. Internally, names
  556. of symbols are ordinarily converted to and stored in uppercase form. There are
  557. ways to force case conversion on output if desired; see *print-case*. In this
  558. book, wherever an interactive exchange between a user and the Lisp system is
  559. shown, the input is exhibited with lowercase letters and the output with
  560. uppercase letters.
  561. [old_change_end]
  562.  
  563. [change_begin]
  564. X3J13 voted in June 1989 (READ-CASE-SENSITIVITY)   to introduce readtable-case.
  565. Certain settings allow the names of symbols to be case-sensitive. The default
  566. behavior, however, is as described in the previous paragraph. In any event,
  567. only uppercase letters appear in the internal print names of symbols naming the
  568. standard Common Lisp facilities described in this book.
  569. [change_end]
  570.  
  571.  
  572.  
  573.  
  574.